Coverage increased (+0.06%) to 40.979% when pulling 27358c3 on bhill-slac:bitsPerPixel into e36ee7c on areaDetector:master.

I am not convinced that BitsPerPixel is something that should be added to NDArray. As far as I can tell its use is mainly as a hint to OPI displays as to the range of intensities to display.

Here are my objections:

• If it is added to NDArray then it should really be added to the pvAccess normative type NTNDArray. But I don't think we want to be changing that.
• I would argue that ColorMode and BayerPattern are more fundamental to proper interpretation of images, but they are not part of the NDArray class. They are implemented as optional attributes. I think that BitsPerPixel should also be an optional attribute.
• In the NDProcessPlugin there is a Sum operation. How shouldBitsPerPixel scale when images are summed? There is also a background subtraction and flat field normalization. How should those affect BitsPerPixel?
• The utility even as a hint to OPI displays seems rather weak. I can have a 12-bit camera but use it under low light conditions so the maximum intensity is less than 255. Is BitsPerPixel=12 really useful in this condition?

Can you explain what the main use of BitsPerPixel is?

Is there any reason it cannot be changed to an attribute like ColorMode and BayerPattern? Remember NDArray is a general purpose N-Dimensional array class, not limited to imaging applications.

Hi Mark,
Yes, the main use is for OPI displays but it's also quite useful when creating 8 bit thumbnail images from 12 bit images. It also has some use in informing the client as to how the original camera bitsPerPixel have been affected by binning and/or scaling operations.

I don't understand your point about BitsPerPixel vs ColorMode and BayerPattern. All 3 are member elements of asynNDArrayDriver in my branch.

Re NDProcessPlugin, I added code to update bitsPerPixel for scaling. I don't think bkgd subtraction or flat field should affect bitsPerPixel and don't see the sum operation in R3=2. Is that something new?

I tend to agree w/ your last point re low light conditions. I've been enabling the scaling in the
aravisGigE cameras which shifts 12 bit (or other) images to make them 16 bit. It accomplishes
much of the same benefits as bitsPerPixel w/ the exception of not providing any info to the client
re effective bitsPerPixel. That would also be an easy place to add an optional shift factor
to make low light images more viewable as long as we clip to all F's.

I don't understand your point about BitsPerPixel vs ColorMode and BayerPattern. All 3 are member elements of asynNDArrayDriver in my branch.

You have added bitsPerElement to NDArray.h as a member of NDArray class. ColorMode and BayerPattern are not members of NDArray, they are NDAttributes. They are "known attributes" in the sense that some plugins look for them and change their behavior based on their presence, or set their values under some circumstances. I think bitsPerElement is in this category of not being a fundamental property of an NDArray.

Re NDProcessPlugin, I added code to update bitsPerPixel for scaling. I don't think bkgd subtraction or flat field should affect bitsPerPixel and don't see the sum operation in R3=2. Is that something new?

Summing is not new, it is one of the things that can be done with the recursive filter. So if I have 8-bit camera images but I sum N of them into a 16-bit output then the value of BitsPerPixel will depend on N.

If the goal is to provide hints to clients for display settings then why not use NDPluginStats to find the Min and Max, or better yet use the Histogram it can produce so single bad pixels don't confuse things?

@bhill-slac are you still interested in pursuing this?

Closing due to inactivity and discussion from collaboration meeting about bitsPerPixel not being enough information to autoscale interfaces